1. Field of the Invention
This invention relates to media in a media library, and particularly to techniques for updating removable media in a media library.
2. Description of Background
In today's computer driven environment, storage of media is an important aspect to consider. For example, media that is stored in a non-intelligent media library has its file system information managed by a controlling server. Sharing this media, when more than one server has access, normally is restricted to read only mode. Implementations allowing updates to this media normally block all other systems from the media until a “checkpoint” is reached. Also, problems with updates include issues such as renaming a mount point, invalidating cached file information, and other complex issues.
FIG. 1 illustrates a traditional implementation of a library controller layer. This process is responsible for moving media such as a tape or optical volume into the data transport element (such as an optical drive). This process is responsible for identifying what is obviously new media (i.e., from the import/export station) from media that should be known (i.e., from a storage slot).
FIG. 2 illustrates a portion of a typical file system with the methods implemented to allow the file system to support a media library implementation. For performance reasons, most file systems maintain a memory copy of frequently accessed data from the media, such as the volume label or volume identifier, the creation date, knowledge of free and used spaces, directory structures, and other information needed to manage the directory. This is well understood by anyone versed in file system implementations. The mount method is unique for media libraries and allows the library controller to ask the file system to verify that the correct physical media was moved into the data transport element (drive).
The controlling system adds media to the media library. Part of this add includes moving the media into a drive and reading file system information from the media (NEW in FIG. 2). This information includes various data, and one item is the “Name” (VOLUME ID) of the media. On system the IBM System i5™ server, this name is registered as part of the file system. For example, if the name is PAYROLL, you would access the data on this media by accessing “/QOPT/PAYROLL”. So this name should not be changed for the duration of the time (perhaps months) that the media is known to the system. To detect a critical hardware problem (such as a robotic error that grabs the wrong media) or a user attempting to be helpful and hand move media, the controlling system needs to validate that the correct media is moved to a drive. This is done by asking the file system to validate the media, which it does by checking that the name on the media matches the expected name.
A second critical piece of information is the record of free and used media space. The file system may choose to pre-allocate media space in the free and used space records on the media and manage that pre-allocated space from its cached information until used up. This approach avoids expensive I/O operations to update the free and used space records on the media, and conserves space within the record structures in the case of permanent WORM media (where sectors can only be written once).
However, this information is not externalized from the file system, so there needs to be a way to recognize that another file system has made updates to the free and used space records on the media or control those updates within a set of checkpoints. Also, current practices have other problems associated with media updates (related to information that is cached) when sharing media. It would be beneficial to have techniques for detecting and controlling the updates of file system structures on the media when that media is being shared in a media library.